The present invention relates to the management of communications in a radiocommunication system.
A radiocommunication system, such as a UMTS (“Universal Mobile Telecommunication System”) system for instance, generally includes a core network (ON) part and a radio access network (RAN). Such system can bear circuit switched (CS) communications and/or packet switched (PS) communications.
A core network comprises interconnected nodes called MSCs (“Mobile Switching Centers”) for the CS domain and GSN (“GPRS Support Node”) for the PS domain. The MSCs which are used as gateways with other networks are called GMSCs (“Gateway MSC”). The GSNs interfaced with a RAN are called SGSNs (“Serving GSNs”), whereas the ones used as gateways towards with networks are called GGSNs (“Gateway GSNs”). The interface between a radio network controller (RNC) of the RAN and a MSC or a SGSN is called Iu interface.
In previous releases of the UMTS standard, a RNC was arranged for cooperating with a respective ON node (a MSO or a SGSN), in a one-to-one relationship. More recently, it has been proposed that a RNC could be connected to several ON nodes belonging to a single CN or different CNs. This is achieved with the mechanism, usually called “Flex” (or “Iu-Flex”), defined in the technical specification 3GPP TS 23.236 version 5.3.0 Release 5, “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (ON) nodes”, published in December 2004 by the 3GPP (3rd Generation Partnership Project).
In a system where the “Flex” feature is implemented, it is specified that the RNO receiving an attachment request from a mobile terminal, called UE (“User Equipment”), forwards it to one of the ON nodes to which the RNO is connected to, in order to share the load between the ON nodes available.
Similarly, when a change of RNO is requested for a communication in progress with a ON node supporting the “Flex” feature, this CN node is supposed to forward the request to a new CN node selected from a set of CN nodes, called a pool area, to which the target RNC is connected to. The new CN node is selected so that the load is shared between the CN nodes of the pool area.
A problem arises when a RNC change is requested, while not all the CN nodes of the system support the “Flex” feature. Indeed, a CN node not supporting the “Flex” feature is capable of forwarding the request only to one predetermined CN node, even though any other CN node in the pool area could have been targeted instead.
Therefore, the load sharing within the pool area can be effective only by manual configuration (see section 4.5 of the above-mentioned TS 23.236). This means that each CN node not supporting the “Flex” feature should be configured with the identity of a determined target CN node of the pool area, in such a way that a load sharing is statistically obtained within the pool area.
However, such manual configuration is subject to human error and the determination of the target CN node for each source CN node adds engineering complexity.
Moreover, since a source CN node not supporting the “Flex” feature always selects the same target ON node, there is a risk to overload the target CN node when the source CN node has a high load capacity, whereas other CN nodes of the pool area may be available.
Besides, if, for any reason, the single target CN node configured in the source CN node fails, the RNC change cannot be achieved, whereas other CN nodes of the pool area may be operable.